1. Field of the Invention
The present invention relates to an information processing system such as a virtual machine system, and more particularly to a method of controlling a running time of a virtual machine in a virtual machine system.
2. Description of the Related Art
An information processing system called a virtual machine system has been realized recently, and its operation mode is being generalized. A virtual machine system configures an information processing system by providing a plurality of virtual machines under a single real machine. A virtual machine control program (hereinafter called VMCP) runs on a real machine and an operating system (hereinafter called OS) runs under the control of VMCP. In general, as an operation mode of a computer constituting an information processing system, there are a method which runs a single OS on a single real machine and a method called a virtual machine (hereinafter called VM or LPAR (logically partitioning)) system which runs a plurality of OSs on a single real machine. A mode of running a single OS on a real machine is called a basic mode. Hardware resources of a real machine used by this mode include one or more central processing units (hereinafter called CPU or IP (instruction processor)), one shared main storage (hereinafter called MS), and one or more channel paths (hereinafter called CHP). These hardware resources of the real machine are used collectively as a unit resource. A mode by which a plurality of OSs run on a plurality of LPARs under a single real machine, is called an LPAR mode.
In general, in order to realize a plurality of LPARs under a single real machine, a program called VMCP is executed on the real machine, a plurality of virtual machines LPARs are formed under the control of VMCP, and an independent OS is made to run on each LPAR. Therefore, VMCP has an additional function of causing each LPAR to share the hardware resources of a single real machine. As a method of causing each LPAR to share the hardware resources of a single real machine, there are a method which time divisionally assigns hardware resources under the control of VMCP, a method which logically divides hardware resources and exclusively assigns them to each LPAR, a combined method of the former two methods for assigning hardware resources, and other methods. For example, as a real CPU sharing method, a method which time divisionally assigns a real CPU to each LPAR has been used, and as a method of sharing input/output channels and MS to each LPAR, a method which logically divides real CHPs and MS and exclusively assigns them to each LPAR has been used. A method of time divisionally assigning a real CPU to each LPAR which may be assumed prior to the present invention, but not admitted as prior art will be described with reference to FIGS. 1 and 2. FIG. 1 is a diagram explaining a real CPU sharing method.
Referring to FIG. 1, a real CPU (hereinafter called PIP) is of a multi-processor structure (hereinafter called MP structure) having two PIPs, PIPA 102 and PIPB 103. PIPA 102 and PIPB 103 are connected to MS 101 and also connected to each other, to realize an MP structure. VMCP capable of controlling the MP structure runs on PIPA 102 and PIPB 103. Two LPARs, LPARA 112 and LPARB 113, are formed under the control of VMCP. LPARA 112 and LPARB 113 are each constituted by two logical CPUs (hereinafter called LIP). Specifically, LPARA 112 configures an MP structure made of LIPAA 121 and LIPAB 122, whereas LPARB 113 configures an MP structure made of LIPBA 131 and LIPBB 132. Therefore, an OS running on LPARA 112 controls LIPAA 121 and LIPAB 122, and an OS running on LPARB 113 controls LIPBA 131 and LIPBB 132. LIPAA 121 and LIPBA 131 run only on PIPA 102, and LIPAB 122 and LIPBB 132 run only on PIPB 103.
Next, the operation of VMCP and each LPAR running on PIP will be explained. FIG. 2 is a timing chart illustrating how real machine resources are distributed to VMCP. LIPAA 121, LIPBA 131, LIPAB 122, and LIPBB 132 when VMCP and each LPAR are dispatched to PIP. As shown in FIG. 2, real machine resources are assigned to VMCP at slots 201, 203, and 205, to LIPAA 121 and LIPAB 122 at slots 202 and 206, and to LIPBA 131 and LIPBB 132 at a slot 204. In this timing chart, PIPA 102 is fixedly assigned LIPAA 121 and LIPBA 131, whereas PIPB 103 is fixedly assigned LIPAB 122 and LIPBB 132.
Slot 201: At the slot 201, VMCP running on PIPA 102 and PIPB 103 sets an operation termination time of LIPAA 121 and LIPAB 122 to internal timers of PIPA 102 and PIPB 103 by using a time slice value (hereinafter called TIMSLC) stored in LPARA 112 for defining a running time of LIPAA 121 and LIPAB 122, and thereafter activates LIPAA 121 and LIPAB 122 to run on PIPA 102 and PIPB 103. At this point, the operations of PIPA 102 and PIPB 103 are moved to a slot 202.
Slot 202: At the slot 202, LIPAA 121 and LIPAB 122 operate while updating the internal timers set at the slot 201 by using TIMSLC. When it becomes the operation termination time of LIPAA 121 and LIPAB 122, the operations thereof are terminated by a timer interrupt to VMCP, and the control is transferred to VMCP. At the time when the control is transferred to VMCP, the operations of PIPA 102 and PIPB 103 are moved to a slot 203.
Slot 203: At the slot 203, similar to the time slot 201, VMCP running on PIPA 102 and PIPB 103 sets an operation termination time of LIPBA 131 and LIPBB 132 to the internal timers of PIPA 102 and PIPB 103 by using TIMSLC stored in LPARB 113 which defines a running time of LIPBA 131 and LIPBB 132, and thereafter activates LIPBA 131 and LIPBB 132 to run on PIPA 102 and PIPB 103. At this point, the operations of PIPA 102 and PIPB 103 are moved to a slot 204.
Slot 204: At the slot 204, similar to the slot 202, LIPBA 131 and LIPBB 132 operate while updating the internal timers set at the slot 203 by using TIMSLC. When it becomes the operation termination time of LIPBA 131 and LIPBB 132, the operations thereof are stopped by a timer interrupt to VMCP, and the control is transferred to VMCP. At the time when the control is transferred to VMCP, the operations of PIPA 102 and PIPB 103 are moved to a slot 205.
Slot 205: The operation at the slot 205 is similar to the slot 201. VMCP activates LIPAA 121 and LIPAB 122 to run on PIPA 102 and PIPB 103, and the operations of PIPA 102 and PIPB 103 are moved to a slot 206.
The operations similar to the above operations are repeated thereafter to time divisionally run LPARA 112 and LPARB 113 on PIPA 102 and PIPB 103. As appreciated from the foregoing description, a time divisional operation of a plurality of LIPs on a single PIP can be realized by the control of VMCP and by using TIMSLC. The conventional technique explained with FIG. 2 assumes that a plurality of LIPs belonging to one LPAR are synchronously activated at the same time. However, in practice, a plurality of LIPs belonging to one LPAR are rarely activated synchronously at the same time, but they are activated randomly, because interrupts other than the timer interrupt occur or some LIPs enter a standby state.
FIG. 3 shows the relationship between LPARA 112, LPARB 113, LIPAA 121, LIPAB 122, LIPBA 131, and LIPBB 132, respectively shown in FIG. 2 and generated by VMCP in a software manner. The former two LPARs and latter four LIPs are generated and controlled as tasks. Specifically, VMCP generates an LPARA task 301, an LPARB task 302, an LIPAA task 311, an LIPAB task 312, an LIPBA task 321, and an LIPBB task 322, respectively for LPARA 112, LPARB 113, LIPAA 121, LIPAB 122, LIPBA 131, and LIPBB 132. VMCP generates the two LPAR tasks when LPAR definition parameters are inputted from an external device, and generates the four LIP tasks when LIP definition parameters and commands are inputted from the external device in correspondence with the two LPARs. TIMSLC for each LPAR is contained in the LPAR definition parameters, and stored in a task control block of each LPAR task when the LPAR definition parameters are inputted. In FIG. 3, TIMSLC for the LPARA task 301 is TIMSLC 305, and TIMSLC for the LPARB task 302 is TIMSLC 307. TIMSLC for each LIP is contained in the LPAR definition parameters and commands, and stored in a task control block of each LIP task when the LPAR definition parameters and commands are inputted. In FIG. 3, TIMSLC 305 for the LPARA task 301 is transferred to a task control block of the LIPAA task 311 as TIMSLC 315a and to a task control block of the LIPAB task 312 as TIMSLC 315b, when the LIP definition parameters and commands are inputted. TIMSLC 307 for the LPARB task 302 is transferred to a task control block of the LIPBA task 321 as TIMSLC 325a and to a task control block of the LIPBB task 322 as TIMSLC 325b, when the LIP definition parameters and commands are inputted. In FIG. 3, the value of RTIMSLC 316a in a task control block of the LIPAA task 311 indicates the time allowing the LIPAA task 311 to run on PIPA 102. The initial value of this value is the same as TIXSLC 315a. The running time from when the LIPAA task 311 is activated to run on PIPA 102 to when the control is transferred to VMCP because of an interrupt or interception, is subtracted from the value of RTIMSLC 316a, and the result is again stored in the area of RTIMSLC 316a. That is to say, the value of RTIMSLC 316a indicates the residual running time of the time slice assigned to the LIPAA task 311. The LIPAA task 311 can run on PIPA until the value of RTIMSLC 316a becomes "0". When the value of RTIMSLC 316a becomes "0", the LIPAA task 311 stops running on PIPA 102 under the control of VMCP until the values of RTIMSLCs of all other LIP tasks become "0". When the values of RTIMSLCs of all other LIP tasks become "0", the value of TIMSLC 315a in the task control block of the LIPAA task 311 is set to RTIMSLC 316a to initialize the latter. The LIPAA task 311 stopped its running again starts running on PIPA 102 under the control of VMCP, by using the initialized RTIMSLC 316a. The same function of RTIMSLC 316a of the LIPAA task 311 is assigned also to RTIMSLC 316b of LIPAB 122, RTIMSLC 326a of LIPBA 131, and RTIMSLC 326b of LIPBB 132.
Referring next to FIG. 4, the running states of VMCP, LIPAA, LIPAB, LIPBA, and LIPBB will be described time sequentially. FIG. 4 is a timing chart illustrating a distribution of real machine resources to VMCP, LIPAA task 311, LIPAB task 312, LIPBA task 321, and LIPBB task 322 when VMCP and each LIP are dispatched to and run on PIP. In this timing chart, the LIPAA task 311 and LIPBA task 321 are fixedly assigned to PIPA, and the LIPAB task 321 and LIPBB task 322 are fixedly assigned to PIPB.
Slot 401: VMCP running on PIPA and PIPB at the slot 401 has already transferred TIMSLC 305 stored in the LPARA task 301 to the LIPAA task 311 as TIMSLC 315a and to the LIPAB task 312 as TIMSLC 315b. Similarly, VMCP has already transferred TIMSLC 307 stored in the LPARB task 302 to the LIPBA task 321 as TIMSLC 325a and to the LIPBB task 322 as TIMSLC 325b. Furthermore, RTIMSLC 316a of the LIPAA task 311 has been initialized to TIMSLC 315a, RTIMSLC 316b of the LIPAB task 312 has been initialized to TIMSLC 315b, RTIMSLC 326a of the LIPBA task 321 has been initialized to TIMSLC 325a, and RTIMSLC 326a of the LIPBB task 322 has been initialized to TIMSLC 325a. VMCP sets the running termination times RTIMSLC 316a and RTIMSLC 316b of the LIPAA task 311 and LIPAB task 312 to the internal timers of PIPA and PIPB, and thereafter, activates the LIPAA task 311 and LIPAB task 312 to run on PIPA and PIPB (at point 451). At this point, the operations of PIPA and PIPB are moved to a slot 402.
Slot 402: At the slot 402, the LIPAA task 311 and LIPAB task 312 run while the internal timers of PIPA and PIPB set at the slot 401 are being updated. During the running of the LIPAB task 312 on PIPB, if an event such as an interrupt other than the timer interrupt indicating an end of the operation termination time (hereinafter called a time slice end or TSEND), interception, and LIP standby is issued to the LIPAB task 312 running on PIPB, the operation thereof is stopped, and the control is transferred to VMCP (at point,452). At this point 452, the operation of the LIPAA task 311 running on PIPA continues. When the control of PIPB is transferred to VMCP, the operations of PIPA and PIPB are moved to a slot 403.
Slot 403: At the slot 403, VMCP running on PIPB stores an updated value of the internal timer of PIPB set at the slot 401 in the LIPAB task 312 as RTIMSLC 316b. The stored value of RTIMSLC 316b indicates the residual time of the operation termination time of the LIPAB task 312. At the slot 403, similar to the slot 401, VMCP sets the operation termination time RTIMSLC 326b of the LIPBB task 322 to the internal timer of PIPB, and thereafter activates the LIPBB task 322 to run on PIPB (at point 453). At this point, the operations of PIPA and PIPB are moved to a slot 404.
Slot 404: At the slot 404, the operation of the LIPAA task 311 running on PIPA from the slot 402 continues, and the LIPBB task 322 starts running on PIPB. During the execution at the slot 404, if an event such as an interrupt other than the timer interrupt of TSEND, interception, and LIP standby is issued to the LIPBB task 322 running on PIPB, the operation thereof is stopped, and the control is transferred to VMCP. At the same time, when it becomes the operation termination time of the LIPAA task 311 running on PIPA, the operation of the LIPAA task 311 is stopped in response to the timer interrupt of TSEND, and the control is transferred to VMCP (at point 454). When the control is transferred to VMCP, the operations of PIPA and PIPB are moved to a slot 405.
Slot 405: At the slot 405, VMCP sets the operation termination times RTIMSLC 326a and RTIMSLC 316b of the LIPBA task 321 and LIPAB task 312 to the internal timers of PIPA and PIPB. In this example, the LIPBA task 321 running on PIPA at its preceding slot has been stopped in response to the timer interrupt of TSEND. Therefore, TIMSLC 325a is set as RTIMSLC 326a. Also because the LIPAB 312 running on PIPB at its preceding slot has been stopped not in response to the timer interrupt of TSEND, the residual time of the operation termination time of the LIPAB task 312 stored at the slot 403 is used as it is. Thereafter, the LIPBA task 321 and LIPAB task 312 are activated to run on PIPA and PIPB (at point 455). At this point, the operations thereof are moved to a slot 406.
Slot 406: During the execution at the slot 406, when it becomes the operation termination time of the LIPAB task 312 running on PIPB, the operation thereof is stopped in response to the timer interrupt of TSEND issued to VMCP, and the control is transferred to VMCP (at point 456). At this point, the operation of the LIPBA task 321 running on PIPB continues. When the control of PIPB is transferred to VMCP, the operations of PIPA and PIPB are moved to a slot 407.
Slot 407: At the slot 407, VXCP running on PIPB stores an updated value of the internal timer of PIPB set at the slot 405 in the LIPAB task 312 as RTIMSLC 316b. The value of this stored RTIMSLC 316b indicates the residual time of the operation termination time of the LIPAB task 312. However, in this example, because the operation of the LIPAB task 312 has been stopped in response to the timer interrupt of TSEND, the value is zero or a negative value. At the slot 407, similar to the slot 403, VMCP sets the operation termination time RTIMSLC 326b of the LIPBB task 322 to the internal timer of PIPB. In this example, the LIPBB task 322 running on PIPB at its preceding slot has been stopped not in response to the timer interrupt of TSEND. Therefore, the residual time of the operation termination time of the LIPBB task 322 stored at the slot 403 is used as RTIMSLC 326b. Thereafter, the LIPBB task 322 is activated to run on PIPB. At the same time, when it becomes the operation termination time of the LIPBA task 321 running on PIPA, the operation of the LIPBA task 321 is stopped in response to the timer interrupt of TSEND, and the control is transferred to VMCP (at point 457). At this point, the operations of PIPA and PIPB are moved to a slot 408.
Slot 408: At the slot 408, VMCP sets the operation termination time RTIMSLC 316a of the LIPAA task 311 to the internal timer of PIPA. In this example, the LIPAA task 311 running on PIPA at the preceding slot has been stopped in response to the timer interrupt of TSEND. Therefore, TIMSLC 315a is set as RTIMSLC 316a. Thereafter, the LIPAA task 311 is activated to run on PIPA (at point 458). At this point, the operations of PIPA and PIPB are moved to a slot 409.
Slot 409: During the execution at the slot 409, when it becomes the operation termination time of the LIPBB task 322 running on PIPB, the operation of the LIPBB task 322 is stopped in response to the timer interrupt of TSEND issued to VMCP, and the control is transferred to VMCP (at point 459). At this point, the operation of VMCP running on PIPA continues. When the control of PIPB is transferred to VMCP, the operations of PIPA and PIPB are moved to a slot 410.
Slot 410: At the slot 410, VMCP running on PIPB stores an updated value of the internal timer set at the slot 405 in the LIPAB task 312 as RTIMSLC 316a. The value of this stored R 316b indicates the residual time of the operation termination time of the LIPAB task 312. However, in this example, because the operation of the LIPAB task 312 has been stopped in response to the timer interrupt of TSEND, the value is zero or a negative value. Also because the operation of the LIPAB task 312 running on PIPB at the preceding slot has been stopped in response to the timer interrupt of TSEND, TIMSLC 315b is set as TIMSLC 316b. Thereafter, the LIPAB task 312 is activated to run on PIPB (at point 460). At this point, the operations of PIPA and PIPB are moved to a slot 411.
After the slot 411, the LIPAA task 311, LIPAB task 312, LIPBA task 321, and LIPBB task 322 alternately run on PIPA and PIPB under the control of VMCP in accordance with the procedure explained with the slots 401 to 410.
As shown in FIG. 4, according to the conventional technique, the LIPAA task 311 and LIPAB task 312 constituting a multi-processor structure and belonging to the LPARA task 301 run at the same time only at the slots 402 and 411, and the LIPBA task 321 and LIPBB task 322 constituting a multi-processor structure and belonging to LPARB task 302 do not run at the same time on PIPA and PIPB. This is because each LIP task manages its RTIMSLC and the timing of TSEND at each LIP task becomes greatly different. This means that the above-mentioned technique does not strictly ensure that a plurality of LIP tasks run at the same time on a plurality of PIPs in the configuration and management of a VM of a multi-processor structure having a plurality of LIP tasks. It is desirable to strictly ensure that a plurality of LIP tasks run at the same time on a plurality of PIPS. The reason for this is that an OS running on a VM of a multi-processor structure having a plurality of LIP tasks uses a multi-processor control instruction and interrupt function while taking the characteristics of a multi-processor into consideration. For example, if a LIP task (a first LIP task) issues a multi-processor control instruction to another LIP task (a second LIP task) and if the second LIP task is not running on the corresponding PIP, the multi-processor control instruction issued by the first LIP task cannot be completed so that the OS running on the first LIP task enters a standby state until the second LIP task becomes active or the control is transferred to VMCP. An occurrence of such an event that the OS running on the first LIP task enters a standby state until the second LIP task becomes active or the control is transferred to VMCP, results in an overhead of the OS running on the first LIP task and a delayed response of the OS. This overhead causes degraded performance of VM.
According to the above-discussed technique, it is not possible to strictly ensure that a plurality of LIP tasks run at the same time on a plurality of PIPs in the configuration and management of a VM of a multi-processor structure having a plurality of LIP tasks. As a result, if an OS running on a VM of a multi-processor structure having a plurality of LIP tasks uses a multi-processor control instruction and interrupt function while taking the characteristics of a multi-processor into consideration, if a first LIP task issues a multi-processor control instruction to a second LIP task, and if the second LIP task is not running on the corresponding PIP, the multi-processor control instruction issued by the first LIP task cannot be completed. The OS running on the first LIP is therefore required to enter a standby state until the second LIP task becomes active or the control is required to be transferred to VMCP. An occurrence of such an event that the OS running on the first LIP task enters a standby state until the second LIP task becomes active or the control is transferred to VMCP, results in an overhead of the OS running on the first LIP task and issued the multi-processor control instruction and a delayed response of the OS. As a result, an overhead of the OS on VM and an overhead of VXCP result in a delayed response of VX. Such an overhead is one cause of a degraded performance of VM not negligible. One of the present applicants discloses related art in JP-A-6-187,178 which is published on Jul. 8, 1994, but not intended as prior art.